개요

서비스의 로드밸런서 유형은 클러스터 외부의 로드밸런서를 기준으로 한다.
내부에서 쓸 거면 어차피 노드포트를 쓰면 되긴 하지만, 여기에 아쉬운 것들이 더러 있다.
일단 클러스터를 구성할 때 설정한 30000과 같은 지저분한..? 포트를 사용해야 한다.
또한 운영 환경에서 로드밸런서를 쓰는데, 테스트 환경에서 빠르게 사용할 수 있는 로드밸런서가 필요할 수 있다.
로드밸런서(마다 다르겠지만)를 통해 트래픽 세부 제어를 하고 싶을 수도 있다.

그래서 온프레미스 로드밸런서를 사용해보고 싶은 나같은 사람을 위한 선택지가 몇 가지 있다.
대표적인 선택지는 MetalLB로, 그나마 오래 된 로드밸런서라 하겠다.
그러나 우리나라에서 메인 기여로 만들어진 LoxiLB가 궁금하기도 했고, eBPF와도 계속 친숙해지는 과정이 필요할 것 같아서 둘 다 세팅해보고 간단하게 비교하는 시간을 가져볼까 한다.

당연하지만 로드밸런서는 클러스터와 무관한 외부 ip를 받을 때까지 제 기능을 하지 못한다.
그래서 온프레미스 로드밸런서는 가상의 ip 대역을 외부 ip인 냥 설정해서 사용해야 한다..

MetalLB 실습

bgp 모드는 직접 다 세팅하기는 어려울 것 같고, layer 2모드를 사용해본다.

먼저 기본적으로 만드려고 했을 때의 모습.
외부 ip를 받지 못하여 펜딩 상태로 대기한다.

기본 매니페스트 파일 설치

헬름으로 처음에 했었는데, 네임스페이스 설정이 없어서 나중에 또 기억하기 귀찮겠다 싶었다.
어차피 계속 활용하지는 않을 것 같아서 양식 파일만 이용해서 설치하기로 마음 먹었다.

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.9/config/manifests/metallb-native.yaml

설치 자체는 매우 간편하게 이뤄진다.
말했듯이 데몬셋으로 스피커가 생기며, 이 친구가 외부 전파의 역할을 맡을 것이다.
그리고 컨트롤러가 생겨서 ip 주소 할당을 담당하게 된다.

나중에 추가한 세팅으로, helm으로 설치하며 커스텀을 진행했다.
여기를 Ignore로 바꿔준다.

기초 세팅

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: ip-pool
  namespace: metallb-system
spec:
  addresses:
  - 192.200.0.0/24

일단 로드밸런서의 외부 ip로 활용될 ip 대역을 설정해야 한다.

apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2ad
  namespace: metallb-system
spec:
  ipAddressPools:
  - ip-pool

그 다음에는 광고를 때린다!
기본 주의점은 스피커 파드가 있는 네임스페이스에 올려야 한다는 것이다.

바로 ip를 부여받았다.
nginx 디플로이먼트를 만들고, 이를 서비스에서 5678포트를 이용하여 연결했다.

너무나도 간단하게 성공했다.
클러스터 노드 하나에 들어가서 해당 ip가 동작하는 것을 쉽게 확인할 수 있다.

패킷 분석

현재 누가 리더 스피커 역할을 하는지 궁금해서 일일히 로그를 뜯어보니 이렇게 찾을 수 있었다.
근데 이제보니 제대로 통신이 안 되는 것 같아 보이는데 어떻게 통신이 된거지..?

해당 로그는 잠깐만 뜬 것일 수도 있는 것 같다.
tcpdump로 패킷을 보니 지속적으로 7946으로 통신이 일어나고 있다.
제대로는 안 찾아봤으나 멤버리스트는 하시코프의 툴을 이용해 리더 선출이나 관련 멤버를 추적할 때 주로 사용하는 것 같다.

순수 tcpdump로는 확인이 조금 힘든 것 같아서 문서에 나온 arping을 활용해봤다.

그러나 아직 잘 모르겠는 것이 많다.
5678 포트로 어떤 패킷이라도 왔어야 하는 게 아닌가?
서비스 포트가 5678이니까, 요컨대 iptables에서 이걸 바꾸는 한이 있었더라도 한번은 패킷이 들어왔어야 하는 것 같은데..

가시다님 스터디에서 나온 공유자료이다.
클라이언트가 서비스 ip로 접속하면 일단 리더 스피커가 있는 노드로 트래픽이 전송돼야 한다.
그 이후 그 노드의 iptables를 통해 트래픽이 분배되는 방식이다.
나는 worker2 노드에 들어가서 패킷을 뜯어보려고 하지만, 제대로 내용물이 나와주질 않는다.

iptables 규칙 확인

어쩌면 iptables에서 이미 어떤 조치가 일어나고 있는 것일지도 모른다고 생각했다.
확인해봤을 때, 로드밸런서 ip는 클러스터에서 바로 파드 엔드포인트로까지 dnat되는 듯하다.
외부(라고 치는)에서 트래픽이 들어올 때도 해당 트래픽은 바로 파드의 엔드포인트까지 가게하는 iptables 규칙이 써져 있는 것이다.
그렇다면 위에서 내가 원하는 결과가 나오지 않은 이유는 명확하다.
내가 curl을 날리는 master 노드에서 이미 dnat된 채로 요청이 날아가기에 내가 걸려고 했던 방식으로 패킷을 추적할 수는 없었던 것이다.

로드밸런서 타입은 노드포트를 노출하고 트래픽 분배는 외부 로드밸런서에게 맡긴다고 하였다.
뭐.. ip로 들어오는 트래픽을 파드의 엔드포인트와 연결시킨다는 서비스의 기본 방침을 다르지는 않는 것으로 보인다.

그런데.. 위에서 내가 이해한 설명은 서비스 ip에 대한 모든 요청은 일단 해당 노드로 가긴 해야 하는데..?
스피커 파드가 한다는 외부 전파 기능은 그럼 무엇인가?
리더 파드가 host network까지 받아서 한다는 것은 arp를 통한 ip 공지라고 했잖나?
그렇게까지 해서 실제 트래픽이 해당 노드로 몰리지 않는다면 위에서 말한 단점은 또 무어란 말인가?

arping을 통해서 어떤 노드에서든 외부 ip에 대한 arping에 대해 저 mac주소를 받을 수 있는데, 이것은 리더 스피커가 위치한 worker2 노드이다.
내 생각대로라면 서비스 ip로의 트래픽은 일단 이쪽으로 오기는 했어야만 했다.
mac 주소도 얻었으니 iptables에 저런 규칙이 없는 채로 그냥 트래픽이 가는 게 맞았다고 생각한다.
그러니까, 로드밸런서 타입에 대해 iptables 규칙이 저렇게 지정되면 안 됐다는 것이다.

로드밸런서 세부 설정에서 노드포트를 지정하지 않고 사용할 수 있게 하는 방법이 있다고 하는데, 이걸 해야만 내가 원하는 방식대로 동작하게 되는 걸까?
내가 현상황을 제대로 이해하고 있는 게 맞다면, 사실 이렇게 동작하는 편이 한 노드에 트래픽이 과다하게 흘러가지 않아 더 이득이다.
같은 대역에서는 어차피 노드들의 iptables 규칙으로 인해 외부 ip로 온 트래픽은 서비스를 거쳐 엔드포인트로 잘만 갈 것이기 때문이다.

노드가 아닌 곳에서 접속한다면?

생각해보니, 노드가 아니면서 인터페이스가 연결된 호스트로 접속할 때 이 효과를 볼 수 있겠다는 생각이 들었다.
garp로 ip에 대한 mac 주소를 노출해준다고 했으니, 같은 대역을 사용하는 인터페이스에만 있다면 iptables 설정이 안 돼있어서 내가 원하는 결과가 나올 것으로 생각된다.

여기, 아무것도 없는 vm 하나가 있다.

해당 vm이 이 인터페이스와 통신을 할 수 있다면, arp 통신을 받을 수 있는 상태라면.

virtualbox에서 만들어질 때부터, private network만 잘 설정하면 이미 같은 인터페이스 상에 위치하게 된다.
구체적으로 말하자면 같은 서브넷 내에 인터페이스가 연결돼 있는 것이다.
그래서 arping도 잘 먹는 게 보인다.

보낼 위치야 알지만, 기본적으로 라우팅 테이블이 없어서 저 대역의 ip를 어느 인터페이스로 보내야 할지 모르는 상태이다.
그렇다면 간단하게 라우팅테이블만 추가해주면 될 것 같다.

ip route add 192.200.0.0/24 dev enp0s8

이것만 해주면 되려나?

갈 위치를 알게 되자 명확하게 트래픽이 전달된다.

이 정도로만 보고, 이제 본격적으로 내가 하려는 것을 해보자.

왜일까, 역시 해당 포트로 접근이 되지 않는 것이 보인다.
아.. 이제야 이해했다.
그러니까 layer2모드에서 스피커 파드가 하는 일은, 정말 garp 밖에 없다.
그래서 같은 네트워크 상에 있는 호스트의 트래픽이 해당 노드로 갈 수 있게 된다.
그렇다고 해서 해당 노드에만 특별한 iptables 규칙이 있는 건 아니다.
아까 위에서 신나게 확인한 iptables 규칙에 따라 처리될 뿐이다.
다시 말해, 일단 노드에까지 들어올 수 있도록 경로를 광고해주고 난 후에는 iptables규칙에 따라 바로 엔드포인트로 가게 된다는 것.

LoxiLB 실습

기본 세팅

LoxiLB도 본격적으로 시도해보자.
관련 실습 가이드가 잘 나와있는 편이다.^[1]

kubectl apply -f https://raw.githubusercontent.com/loxilb-io/kube-loxilb/refs/heads/main/manifest/in-cluster/loxilb-nobgp.yaml

일단 loxilb 자체를 클러스터 내부에 쑤셔박는다.
원래는 no-bgp 양식 파일로 나와있다.

세가지 오브젝트가 들어왔다.

내 맘대로 받은 죗값인지 문제가 있다.
데몬셋이 어디에도 파드를 스케줄링하지 않는다.

어피니티 설정이 걸려있는데 내 마스터에는 node-role master 라벨따위 존재하지 않는 걸..

바로 스케줄링되기 시작한다.
no-bgp가 아닌 모드에서는 컨트롤 플레인에만 설치되도록 설정돼있는데, 어떤 차이가 있어서 이렇게 돼있는지는 모르겠다.

wget https://raw.githubusercontent.com/loxilb-io/kube-loxilb/refs/heads/main/manifest/in-cluster/kube-loxilb.yaml

그 다음 로밸컨 역할을 해줄 kube-loxilb를 설치하는데, 조금의 설정을 위해 양식파일만 받는다.

이 부분에 대해서 설정을 해줄 것이다.

args: 
	#- --loxiURL=http://192.168.80.10:11111 
	- --cidrPools=defaultPool=192.168.80.100/32 
	- --setRoles=0.0.0.0 
	#- --setBGP=64512 
	#- --listenBGPPort=1791 
	#- --monitor 
	#- --extBGPPeers=50.50.50.1:65101,51.51.51.1:65102 
	#- --setLBMode=1

bgp 관련 설정을 주석 처리하고, cidr 범위를 세팅한다.
온프렘 전용으로 나온 로드밸런서는 metallb이고, loxilb는 클라우드에서도 실행될 수 있도록 설계됐기 때문에 조금 더 신경 쓸 부분이 있다.

이 인자는 꼭 주석 처리가 돼야 한다.

이건 있어야 인 클러스터로 동작하는 듯하다.
엔드포인트와 full nat로 통신할 때 소스 ip로서 동작한다고 한다.

예제에 나온 양식을 그대로 실행해봤는데.. external ip가 신기하게 찍힌다?!

상태를 보니 외부 ip에 대해서 노드포트로 연결되도록 되어있는 듯하다.
상태를 보니 active라서 잘 되고는 있는 듯하나..
파드에 들어가서도, 노드에서도 통신이 되질 않는다.

트러블 슈팅

kube-loxilb는 기본으로는 bgp를 사용하게 할 수 있다..^[2]
위에서 잠시 봤던 다른 선택지라고 할 수 있겠다.
하지만 나는 no-bgp로 설정을 하고 있는데.. 흠
기본으로는 bgp를 사용하는 Calico를 쓰고 있는 게 이슈일 수도 있다고 생각했다.

일단 이렇게 bgp라는 것을 확인해볼 수 있다.^[3]
외부에 loxilb를 설치할 때 기준, 칼리코가 bgp일 때 loxi도 bgp여야 한다고 한다.^[4]
내부에서도 그러한가? 칼리코가 사용하는 as에 맞춰서 다시 한번 세팅해보자.
cni가 bgp 를 제공하고 있다면 사용하지 말라는 글도 있어서 조심스럽다.

너무 무턱대고 하려는 것 같아서 조금 정리가 필요하다.

상황 파악

처음 보는 게 워낙 많아서 헷갈리고 있는데, 이 사태의 근본을 파헤쳐보자.
로드밸런서는 본인이 세팅이 되었다고 했다.
노드 포트 호출도 문제 없다.
그러나 노드나 파드에서 로밸 ip로 호출이 불가능하다.

그렇다면 metallb와의 차이는 무엇이 있는가?

일단 ip.. 비스무리한 게 로드밸런서 status에 뜬다.
난 처음에 저게 도메인 네임이라도 되주는 건가 했는데, 아무튼 중요한 건 저 ip로 통신이 안 된다는 것이다.

iptables 규칙은 생기기는 했으나, 외부 ip에 대한 규칙이 생성되지는 않았다.
이제보니까 이거 우연히 200으로 그렙했다가 찾은 거네..?

조금 더 뒤져봤는데, iptables 규칙은 cluster ip와 nodeport에 대해서만 생겼을뿐, 역시 외부 ip와는 관련이 없다.
ebpf를 통해 이 스택을 우회해버리니 사실 이건 당연하다 생각한다.
(서비스 프록시에 대해서 loxilb를 적용하는 방법까지 동원하게 된다면 저 cluster ip도 안 생길 수도 있겠다.)

의심 사항들

잘 모르니까 일단 짚이는 부분 다 짚어보자.

• 게이트웨이가 안 뚫려 있어 문제가 된다.
  • 근데 이거 metallb에서 하듯이 동일하게 해봤으나 안 됐다.
  • 
  • 하지만 생각해보면 클라쪽에서는 갈 경로를 지정하는 게 필요하니 이것도 하나의 이유이긴 할 것이다.
  • 아예 라우팅할 호스트가 없다 떠버리는 건 처음 봤다..
  • 인터페이스를 잘못 연결했나?
• loxilb는 컨트롤 플레인에만 있어야 한다는 것 같다.
  • 그냥 예제로 받은 nobgp 데몬셋에는 어피니티가 주석 처리돼있어 그대로 사용하긴 했다.
  • 이게 문제인지는 확인하기 쉬우나, 아닐 것 같다..
• 원래 가이드는 Flannel을 쓰지만 나는 Calico를 쓰고 있다.
  • 이것도 유력하게 의심되는 상황이긴 한데, 계속 찾아보니 인 클러스터에서 cni가 bgp면 bgp를 비활성화하는 게 맞다는 것 같다.
  • 위의 것과 더불어서, bgp peer가 필요없다는 뜻을 내가 곡해한 것일 수도 있다.
• 오브젝트 상태 추적에 아직 이슈가 있다.
  • 이미 클러스터에 올라간 로드밸런서 포트를 edit해서 수정해보니 서비스의 포트는 바뀌는 것을 확인했으나, loxicmd로는 이 변화가 추적이 되지 않았다.
  • 내 임의의 수정이기에 이슈가 있었을 수도 있으나, 한편으로는 loxilb의 각 모듈 간 상호작용 과정 상에서 디버깅한답시고 내가 올렸다 내렸다 하며 생긴 변화들이 제대로 적용이 안 되고 있을 가능성을 생각해볼 수 있을 것 같다.

아는 수준이 얕아서 일단 이 정도가 생각이 드는데..

추가 조사

게이트웨이 세팅을 하지 않으면 이렇게 패킷이 저 세상으로 날아가버리니 일단 게이트웨이 세팅은 역시 필수이다.

이번에는 아예 가상 대역 풀을 바꿔봤다.
같이 쓸 수 있는 대역을 활용해본다.

음.. kube-loxilb에서 lbmode 인자를 1로 줘봤는데, 갑자기 아예 연결이 안 된다.
1은 onearm모드였다.
기본값인 0은 dnat로, source ip는 유지되는 모드이다.
source ip가 유지되니 값이 돌아오는 것일 수도 있다.
근데 onearm은 패킷이 돌아오지 않는다..
그렇다면 loxilb의 설정을 따라 패킷이 이동은 하고 있다는 것인가?

ebpf가 참 디버깅을 어렵게 하네..
잘 모르는 상태에서 어디에서 문제가 생겼나 추적하려니 이리저리 헷갈린다.

뭔가 계속 헛다리를 짚고 있는 것 같다.
해당 ip로 curl 요청을 날리면 왜인지 lo 인터페이스로 요청이 날아가고 있다.

분명 ip route로만 봤을 때는 저 주소가 enp0s8 인터페이스로 간다고 나오지만, 막상 get을 해보니 결과가 달랐다.

흠.. 이걸 지우고 다시 해봐도, 바로 다시 lo 인터페이스에 해당 대역이 붙어버린다.
curl --interface enp0s8로 인터페이스를 고정하면 라우팅할 호스트가 없다는 응답이 돌아왔다.

내 생각에는, 이 지점부터 이미 문제가 발생하고 있는 게 아닌가 싶다.
이리 저리 세팅을 바꾸다가 다시 192.200.1.1로 cidr풀을 만들었는데, route 테이블에 추적이 되지 않는다.
그렇다면 loxilb는 도대체 어디에 해당 주소를 광고한단 말인가?
내부적으로 ebpf를 이용해 무얼 하든 간에, 최소한 인터페이스를 타고 들어와야 패킷을 처리하든 말든 할 것이다.
그런데 이렇게 돼있으면 항상 해당 주소를 통한 요청은 디폴트로 빠질 수밖에 없다.

방향 선회 - bgp

bgp를 적극 활용하는 방향으로 가보자.
일단 Calico가 사용하는 bgp를 클러스터 바깥에서도 받을 수 있게 한다.^[6]
결국 bgp를 사용하게 되는 구만.
내 하꼬 vm에 bgp 라우팅 소프트웨어 설치!

외부 bgp 피어 구성

먼저, 이걸 해주는 것은 bgp 피어링이 제대로 되는지 확인하기 위함이다.
이걸 해주고 난 후 loxilb에서 bgp가 설정되는 방식을 조금 더 구체화시킨다.

가장 위에 있는 bird를 사용해보자.

apt install bird

하하 시작부터 커널 업그레이드하라는 말부터 나오네 좋아좋아

/etc/bird/bird.conf에서 각종 설정을 해준다.

router id 192.168.56.2;  # VM의 라우터 ID 설정
protocol bgp {
  local as 65001;  # VM의 ASN
  neighbor <클러스터 IP> as <클러스터 ASN>;
}

여기에서 나는 프라이빗 네트워크에서 받은 번호가 아닌 다른 주소를 주었다.
bgp가 잘 된다면, 그렇게 하더라도 문제될 건 없을 거라고 생각했다.
이웃은 하나만 있어도 될 거라고, 일단 감안하고 세팅해본다.

sudo systemctl start bird
sudo systemctl enable bird

birdc를 통해 조작을 할 수 있다.

apiVersion: projectcalico.org/v3
kind: BGPPeer
metadata:
  name: bfg-peer
spec:
  peerIP: 192.168.56.20
  asNumber: 65001

칼리코에서는 이렇게 설정해주면 된다고 해서 해봤는데, 왜인지 crd가 없다고 한다.

v1이라, 설치된 칼리코 버전은 3.25던데.
그리고 이쪽은 당연스레 crd가 앞에 붙어있다..?

일단 해당 오브젝트가 등록은 됐으나..

라우팅될 호스트가 없다고 나온다.
이거야 말로 게이트웨이 이슈인 듯하다.

받는 측에서 해당 ip가 내 꺼다 하게 만든다.

오오잉.. connection refused라..
ping이 가는 건 확인했으니, 이건 포트가 닫힌 이슈일 수도 있다.
보통 클러스터를 쓰면 iptables를 그냥 클러스터 차원에서 마구 수정해버리니까 문제가 없겠지만, 이쪽은 다르니까.

과연, bgp로 패킷이 날아오는 중이다.

칼리코 bgp 기본이 full mesh라 그런지, 모든 노드에서 요청이 오는 중이었다;;

포트를 명시하지 않아서 생기는 문제가 아닐까 했는데, 그건 아니었고, 문서를 보면서 보니까 이렇게 각각을 프로토콜 블록으로 만들어주면 되는 거였다.
에러 로그도 잘 나와서 보기 편했다.

그래서.. 일단 됐습니다.

ip route에서도 확인되나 했는데.. 일단 birdc 커맨드로 볼 수 있다.^[7]

이렇게 조금 더 상세한 정보를 볼 수 있다.
흠.. 아무런 설정을 하지 않았는데 output이 reject인 건 클러스터 쪽에서 거부하는 걸까?
ASN이 달라서 ibgp로 설정되지는 않았을 텐데.

호스트에서 요청이 계속 안 가길래, 무엇인가 했는데 이제 보니 export all;부분이 주석 처리 돼있었다;

아주 성공적으로 내 따까리 호스트의 라우팅 테이블에서 파드 ip 대역을 확인할 수 있다.

이건 왜일까, ping도 되고 경로 추적도 된다.
그런데 curl 요청을 받지를 않네?

서비스의 클러스터 ip로 보내봤을 때도 안 받다가, 노드 포트로는 잘 받는다.
아하, 추가적인 설정을 하게 만들어뒀다.^[8]
어차피 연결되는 것은 확인을 했으므로, 여기에서 더 추가적으로 설정하진 않겠다.
이제는 다시 loxilb로 돌아간다.

loxilb bgp 설정

https://ko.loxilb.io/post/k8s-understanding-nuances-of-in-cluster-external-service-lb-with-loxilb

오늘 확인해보니 왜 몇 페이지가 없어졌지..?
했는데 다른 루트로 들어가보니 또 있다.

뭔가 업데이트 중인 건지 502가 뜬다.

아무튼, 이번에는 bgp 모드로 실행해본다.
ext가 클러스터 외부를 뜻하는 건지, 아니면 칼리코의 가상 라우터까지 포함하는 건지는 모르겠다.

근데 이제보니 loxilb를 노출하는 서비스가 헤드리스라..그리고 그 파드는 호스트 네트워크..
칼리코에 bgp peer를 그럼 노드 ip로 등록해야 한다고..?

이렇게 넣어서 잘 될리가 있나..

일단 같은 피어면 해당 라우터가 뜨질 않는다.
피어 번호를 다르게 해보고, 포트를 지정도 해봤다.

경로 문제가 확실하게 있다.
이런 경우에는 어떻게 해야 하나?
음. 사실 정확하게 loxilb가 어떻게 bgp를 사용하는지에 대한 구조를 모르니 명확하게 대응할 수가 없다.

문서 확보

https://github.com/loxilb-io/loxilb/blob/main/cicd/k8s-calico-incluster/node_scripts/master.sh
단서를 찾았다.
여태 내가 하던 세팅과 크게 다른 건 없어보이는데..

• 여기는 ipvs 모드를 사용하고 있다.
• cir-dockerd를 cri로 쓴다.
• 칼리코는 그냥 세팅이므로 bgp ipip가 세팅될듯하다.
• loxilb-ebpf 관련 빌드하는 게 있는데, 이걸 실행은 안 하니까 실제로 적용이 안 되는 것 같은데..
• loxilb에서는 bgp 세팅을 하지 않는다.
• kube-loxilb에서도 bgp는 세팅하지 않는다.

그럼 결국.. ipvs빼곤 다른 게 없는 것 같은데..?
직접 해보기 이전에, 마지막으로 이걸 정답지 삼아 내 클러스터에 적용해보자.

클러스터의 누군가는 이 요청을 받고 있다.

저번과 동일하게 클러스터의 호스트에는 lo 인터페이스에 해당 주소가 생겼다.

순간 됐나 했는데 생각해보면 nodeport로 들어오기만 하면 호스트는 받아줄 준비가 돼있어서 상관이 없다..

문서 그대로 적용해보기

최후의 방법이다.
이것도 안 되면, loxilb측에 연락을 해보던가 포기하겠다.

아오 두 번이나 실패했다.

시간이 오래 걸려서 딴 일하고 있었는데, 이제보니 이런 이슈가 있다.

vagrant 자체부터 문제가 발생하고 있다.
찾아보니 아주 고질적인 문제인 것 같은데, 압축 파일을 해제할 수 없을 때 발생하는 것 같다.
그러나, 마지막 에러에 대한 글이 거의 19년도인데 지났는데도 일어난다는 것은 개발진이 제대로 커버 치지 못하는, 신경 쓰지 못하는 영역의 일인 듯하다.
명확한 에러 해결법도 존재하지 않는 것으로 보인다.
다양한 이유로 발생할 수 있는 사항이라고 생각해볼 수 있을 것 같다.
여기에서부터 문제가 발생한다니..
그럼 내가 평소에 사용하던 박스 이미지를 사용해보겠다.
음, 원인을 확실시할 수 없으나 이 정도의 이유가 있을 수 있으려나.

• 현재 box 저장소에 문제가 생겨서 원격으로 받아오는 게 불가능하다.
• vagrant가 최근에 업데이트됐는데, 이때 linux 버전에 버그가 생겼다.
  • 안 그래도 자동완성 모드가 제대로 적용되지 않는 이슈가 있긴 했다.
• 내 os와 호환이 되지 않는 이미지다.
  • cpu는 같다고 나오는데, 이럴 거면 vm 왜 쓰냐?

최대한 제공된 스크립트를 쓰려고 했으나, 이런 에러가 계속 뜨는 관계로 직접 구축하기로 마음 먹었다.
내가 직접 터미널에 입력해서하는 건 또 괜찮더라고..?

아무튼 해봤는데.. 전부 실패한다.

혼자 하는 게 막혀서 정답지를 가져왔는데, 정답지에도 정답이 없으면 나로서는 어쩔 수 없다고 생각한다.
이 놈은 아예 외부 ip를 할당 받지도 못하고 있는데 뭐..

loxilb 자체의 로그를 뜯어봤더니 이렇게 나온다.
뭔가 ebpf 관련 안 된 게 있는 건가?

해당 파일이 없기는 하다.

포기하기 전에, 연락이라도 한번 해보자.
cni 문제이려나.. bpf 설정이 덜된 걸까.. 정말 몰루겠다요..
최소한 외부 ip를 할당받는 것을 성공했던 시점에는 어떻게 해야 트래픽을 보낼 수 있었던 걸까..

관련 문서

참고